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1 Executive Summary 


This report was prepared by atsec information security corporation to review aspects of the 
security and integrity of the Dominion Democracy Suite 4.14-A Voting System. It identifies the 
security vulnerabilities found through static code review and by searches of public 
vulnerability sources that could be exploited to alter vote recording, vote results, critical 
election data such as audit logs, or to conduct a denial of service attack on the voting system. 


The most significant vulnerability found was that the voting system generates weak keys 
used for a variety of purposes. A knowledgeable attacker could crack these keys in a matter 
of hours with commodity resources. 


Moderate vulnerabilities found include: 


complex control flow 

use of cryptographic algorithms and modes considered insecure by NIST 
implementation and design are inconsistent with respect to cryptography 
¡Button functionality may be bypassed through developer debugging code 
privilege escalation issues 

hard-coded encryption keys 

no detection of overflows in vote counting arithmetic 


In addition, numerous less severe but still noteworthy vulnerabilities were found related to 
code quality and non-conformance to the 2005 Voluntary Voting System Guidelines. See 
Chapter 3 for all findings. 
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2 Introduction 


This report was prepared by atsec information security corporation to review aspects of the 
security and integrity of the Dominion Democracy Suite 4.14-A Voting System. It has been 
prepared in support of a contract awarded to Freeman, Craft, McGregor Group, Inc. This 
project has a goal to provide voting system test support services to assist the California 
Secretary of State (SOS) with the evaluation of the Dominion Democracy Suite 4.14-A (EAC 
Certification Number: DemSuite-4-14-A) Voting System for its suitability for use in the State of 
California in accordance with Elections Code sections 19001 et seq. 


The source code review was performed by the following atsec information security 
corporation consultants: 


e Jeremy Powell 

e Hedy Leung 

e King Ables 

e Swapneela Unkule 


This document identifies the security vulnerabilities found through static code review and by 
searches of public vulnerability sources that could be exploited to alter vote recording, vote 
results, critical election data, such as audit logs, or to conduct a denial of service attack on 
the voting system. 


2.1 Scope and Basis 


The Dominion Voting Systems Democracy Suite Version 4.14-A Voting System (hereafter 
referred to as the “voting system” or simply as the “system”) is a paper ballot-based, optical 
scan voting system. The system hardware consists of four major components: 


e The Election Management System (EMS) 

e ImageCast Evolution (ICE) precinct scanner with optional ballot marking capabilities 
e ImageCast Central (ICC) central count scanner 

e Adjudication system 


atsec performed the code review on the basis of the Statement of Work between Freeman, 
Craft, McGregor Group Inc. #13S52044 with the State of California, which states that review 
includes evaluating the security of the system as it is allowed to be configured for use by the 
State of California (hereafter referred to as “the California configuration”). The threat model 
below defines the scope of this examination. 


2.2 Inputs 


The reviewers were provided with a set of documents that support the findings in this report. 
These documents were examined during the source code review to better understand the 
voting system and identify discrepancies between the documentation and the source code. 
These documents are listed in the References chapter. 


The reviewers were also provided with the source code for the following components: 
e The Election Management System (EMS) 
o EMSAuditModuleSourceCode package 1.0.1 
o EMSAuditModule 1.0.1 Outputs 
o EMSSourceCode package 4.14.23 
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o EMS Outputs 
e ImageCast Evolution (ICE) 
o ICE Outputs 
o ICE 4.14.10 
e ImageCast Central (ICC) 
o ICC Outputs 
o ICC 4.14.4 130321 
e Adjudication system 
o Adj _1.0.14.17603 Source 20130523 
o Adjudication Outputs 


2.3 Threat Model 


This assessment is centered on the threat model prescribed in the Statement of Work. The 
system is expected to counter the following attacks: 


e Alter vote recording 

e Alter vote results 

e Alter critical election data, such as audit logs 

e Conduct a denial of service attack on the voting system 


To the extent possible, vulnerabilities found have been reported with an indication of whether 
the exploitation of the vulnerability would require access by the: 


e Voter: Usually has low knowledge of the voting machine design and configuration. 
Some may have more advanced knowledge. May carry out attacks designed by others. 
They have access to the machine(s) for less than an hour. 


e Poll worker: Usually has low knowledge of the voting machine design and 
configuration. Some may have more advanced knowledge. May carry out attacks 
designed by others. They have access to the machine(s) for up to one week, but all 
physical security has been put into place before the machines are received. 


e Elections official insider: Wide range of knowledge of the voting machine design 
and configuration. May have unrestricted access to the machine for long periods of 
time. Their designated activities include: 


o Set up and pre-election procedures 
o Election operation 

o  Post-election processing of results 
o Archiving and storage operations 


e Vendor insider: Has great knowledge of the voting machine design and 
configuration. They have unlimited access to the machine before it is delivered to the 
purchaser and, thereafter, may have unrestricted access when performing warranty 
and maintenance service, and when providing election administration services. 


The atsec team did not attempt to demonstrate exploitability of identified potential 
vulnerabilities. However, identified potential vulnerabilities were described along with the 
anticipated factors necessary to mount an attack. 
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2.4 Methodology 


The atsec team used the following methodology for the source code review. 


2.4.1 Published vulnerabilities 


The reviewers searched the MITRE Common Vulnerability and Exposures (CVEs) list and the 
Common Weakness Enumeration (CWEs) list to identify vulnerabilities that affect the system. 
Although these lists may not have entries for the voting system itself, constituent software 
that the voting system uses may contain vulnerabilities. The review team identified software 
that the system relies upon and conducted searches for these products as well. 


2.4.2 Code quality 


While performing the examination of the code for other activities, the reviewers identified and 
recorded areas within the code base that demonstrate poor code quality. Although poor code 
quality does not necessarily identify vulnerabilities, it does provide an indication that 
vulnerabilities may exist. 


The following coding standards were used during this analysis: 


e 2005 Voluntary Voting System Guidelines [VVSG1], [VVSG2] and supplemental 
interpretation statements found at: 
http://www.eac.gov/testing_and_certification/request_for_interpretations1.aspx 


e Dominion Democracy C/C++ Coding Standard [DSCODE] 


Note that [DSCODE] is not a “published, reviewed, and industry-accepted” standard, so is 
ineligible as an exemption for any requirement in [VVSG2] Section 5. 





The reviewers also compared the code against software engineering best practices. Examples 
of best practices can be found in the following books: 


e The CERT Oracle Secure Coding Standard for Java [CERTJ] 
e The CERT C Security Coding Standard [CERTC] 


These standards are based on accepted industry best practices in developing C/C++ code 
and in managed code (e.g., Java, J#, C#). The system does not appear to contain Java source 
code, but the standard still provided useful input into the analysis of the code quality. 


The team also performed numerous informal static analysis activities on the source code to 
gather code quality data using both source code analysis tools and customized command 
scripts. 


2.4.3 Design 


The source code review team used the usage and installation guidance, source code, and any 
material provided or otherwise publicly available to construct an understanding of the 
architecture and design of the voting system. This understanding included discovering the 
external interfaces and their security mechanisms and controls, particularly as much 
information as possible was gathered to support conclusions regarding the ability for a threat 
agent to tamper with or circumvent security controls. 


The design description also provided a mapping from the high-level features and interfaces of 
the product down to where the reviewers believed those features and interfaces are 
implemented. 


Interfaces represent the primary attack surface of the voting system. Interfaces can include 
web-based interfaces, native graphic user interfaces, command line interfaces, or technical 
interfaces that are not designed for direct user interaction (e.g., database connections). Each 
of these interfaces was examined to identify the security controls that counter the threats. 
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Secure interfaces also depend on filtering out poorly structured or corrupt data. The review 
team specifically checked for input validation mechanisms and determined if related attacks, 
such as command injection are possible. 


2.4.4 Cryptography 


While cryptography is often the hardest security mechanism to break directly, misuse of 
cryptographic primitives can render that protection weak or non-existent. The review team 
identified use sites of cryptography throughout the source code and determined if its use is 
appropriate for the given purpose. For example, using a cryptographic hash function to 
protect passwords is appropriate while using an encryption algorithm with a hard-coded key 
is not. 


2.4.5 Back doors 


Those with access to the voting system during development with malicious intent can place 
back doors into the source code so that they could gain unauthorized access to the voting 
system during operation. Back doors are extremely hard to find because a seasoned 
programmer can obfuscate code to look benign. 


The review team marked areas of vulnerabilities as identified above for further scrutiny. For 
example, a particular area of code may have poor code quality and accesses sensitive 
information such as authentication credentials might be a good place to hide a back door. 
The reviewers treated such areas with extra scrutiny by considering insider threats in 
addition to unintentional implementation flaws. 


2.4.6 Measurement of findings 
A summary of findings is listed in Chapter 3. Each finding contains: 
e A description of the vulnerability or weakness. 


e An assessment of what threats are involved in the possible exploitation of the 
vulnerability or weakness. 


e A categorization of the findings, which can be: 


o A weakness in the source code. Weaknesses are issues identified in the source 
code that are not directly exploitable but may indicate the existence of exploitable 
vulnerabilities within the source code. 


o Anonconformity in the code quality standards. Nonconformities do not necessarily 
imply weaknesses, though the rationale for the requirement is often based on 
preventing weaknesses. 


o A potential vulnerability in the source code. The reviewers consider potential 
vulnerabilities to likely be exploitable. 


o A vulnerability in the source code. The reviewers have either shown or have 
referenced other parties who have asserted the vulnerability to be exploitable. 


e A severity level of the findings, which can be either: 


o A low severity finding. Low severity implies either the impact to the product is low 
or already mitigated by the system, or the difficulty in exploitation would likely 
require indefinite access to the systems, expert knowledge of the system, or would 
require cost prohibitive resources. 


o A medium severity finding. Medium severity implies either the impact of 
exploitation to the product would be significant, or the difficulty in exploitation 
would likely require extended access to the systems, informed knowledge of the 
system, or would require significant resources. 
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o A high severity finding. High severity implies either the impact of exploitation to 
the product would result in complete compromise of security, or the difficulty in 
exploitation would likely require little to no access or knowledge of the systems or 
little to no resources. 
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3 Findings 


The following table summarizes the findings that arose from the source code review team's 
assessment of the voting system. Potential exploitation of a weakness or vulnerability and 
type of attacker is noted where applicable. 





ID 


Description 


Assessment 


Categorization 





1 


Catchall catch-blocks in 
try-catch statements. 


Catchall catch-blocks may 
not handle some 
exceptions appropriately. 
Maliciously crafted input 
may cause denial of 
service or otherwise 
undefined behavior. 


Type: Weakness 
Severity: Low 





Try-catch statements do 
not handle all potential 
exceptions. 


Uncaught exceptions are 
thrown to the calling 
function. Maliciously 
crafted input may cause a 
denial of service. 


Type: Weakness 
Severity: Low 





Non-descriptive constant 
names. 


Many constants in the 
source code have 
identifiers that describe 
the value of the constant 
rather than the concept it 
represents or its usage. No 
flaws were identified, but 
the style is not robust to 
implementation flaws. It 
also makes source code 
review difficult. 


Type: Weakness; VVSG 
nonconformity 
Severity: Low 





Non-descriptive 
comments. 


Comments intended to 
describe the code often re- 
state the code rather than 
explain what it is doing 
semantically. No flaws 
were identified, but the 
style is not robust to 
implementation flaws. It 
also makes source code 
review difficult. 


Type: Weakness; VVSG 
nonconformity 
Severity: Low 











Inconsistent comments. 





Comments were observed 
to be copy-and-pasted 
without further updates, 
leaving them inconsistent. 
No flaws were identified, 
but the style is not robust 
to implementation flaws. It 
also makes source code 
review difficult. 





Type: Weakness; VVSG 
nonconformity 
Severity: Low 
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Description 


Assessment 


Categorization 





6 (Switch statements do not 
have default cases. 


When no default cases 
exist, control may pass 
through the switch 
statement without proper 
processing. No flaws were 
identified, but the style is 
not robust to 
implementation flaws. 


Type: Weakness; VVSG 
nonconformity 
Severity: Low 





7 |Single-statement control 
structures do not enclose 
statement with braces. 


Single-statement control 
structures are not robust to 
development regressions. 
No flaws were identified, 
but the style is not robust 
to implementation flaws. 


The reviewers explicitly 
relate this weakness to the 
recent Apple GOTO fail 
flaw. See 
http://www.wired.com/thre 
atlevel/2014/02/gotofail/ 
for further details. 








Type: Weakness; VVSG 
nonconformity 
Severity: Low 





8 Code extends beyond 80- 
character width limit 
specified by VVSG. 


The source code often 
exceeds the limit by only a 
few characters. In some 
more rare cases it extends 
further. The reviewers do 
not consider this a security 
related issue and did not 
find that it detracts from 
readability. 


Type: VVSG nonconformity 
Severity: Low 





9 |Member variables are not 
initialized in the 
constructor. 


Some classes were 
identified that did not 
initialize member 
variables. 


Type: Weakness; Dominion 
Style Guide nonconformity 
Severity: Low 





10 |The claim of FIPS 
compliance is not 


confirmed. 











ICE and ICC use the 
OpenSSL module for 
cryptographic algorithms. 
The version of OpenSSL 
used by ICE cannot be 
confirmed to be FIPS 140-2 
validated by the CMVP. The 
ICC uses a validated 
OpenSSL module. 





Type: Weakness 
Severity: Low 
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ID |Description Assessment Categorization 





11 |No password guessing The password verification |Type: Vulnerability 
prevention. mechanism in ICC does not | Severity: Low 
slow the rate of password 
guesses nor does it 
prevent access after a 


Might be exploited by a poll 
worker or elections official 











certain number of insider. 
attempts. 
12 [Some modules do not Modules are required to Type: VVSG nonconformity 
include header have header information Severity: Low 
information required by (including the purpose of 
VVSG. the unit and how it works, 
other units called, input 
parameter description, 
output description, file 
references, global 
variables, and revision 
record. 
13 Some variable VVSG states that all Type: VVSG nonconformity 
declarations do not variables shall have Severity: Low 
include explanatory comments at the point of 
comments as required by | declaration clearly 
VVSG. explaining their use. 
14 |Mixed-mode operations |VVSG states mixed-mode Type: VVSG nonconformity 
exist counter to VVSG operations should be Severity: Low 
requirement. avoided or at least clearly 


explained if necessary. 
Several instances were 
found that did not provide 
any rationale. 





15 |Complex branching The developers use an Type: Weakness 
structure. uncommonly complex Severity: Medium 
branching style for 
handling errors. No flaws 
were identified, but the 
style is not robust to 
implementation flaws. It 
also makes source code 
review difficult. 
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ID |Description 


Assessment 


Categorization 





16 |Incorrect HMAC 


invocation. 


Although the 
documentation describes 
the use of an HMAC for 
integrity protection, SHA- 
256 is used instead. 
Inconsistency with 
documentation is a low 
severity, however since it 
relates to cryptography, it 
has a higher potential 
impact on the security of 
the system. 


Type: Weakness 
Severity: Medium 





17 |User is allowed to select 


weak RSA keys. 


The system allows the user 
to select the size of RSA 
keys, including 1024 bits. 
NIST no longer considers 
1024-bit RSA keys to be 
secure. 


Type: Weakness 
Severity: Medium 


Might be used even accidentally 
by an elections official insider 
and then exploited by a poll 
worker or elections official 
insider. 





18 |Use of SHA-1 in RSA 


signature generation 


NIST no longer considers 
SHA-1 as an appropriate 
cryptographic hash for 
digital signature 
generation after 2014-01- 
01. 


Type: Weakness 
Severity: Medium 








and decryption for use 
other than key 
distribution. 











files using RSA. Encryption 

and decryption with RSA is 

not considered appropriate 
by NIST unless used for key 
distribution. 


19 Use of MD5 NIST no longer considers Type: Weakness 
MD5 as an appropriate Severity: Medium 
cryptographic hash in FIPS 
140-2. 

20 ¡Use of RSA encryption The system protects some | Type: Weakness 


Severity: Medium 
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ID |Description Assessment Categorization 
21 |Confidentiality and The description of the use | Type: Weakness 
integrity protection of cryptography in the Severity: Medium 
implemented by code is ¡documentation is 
inconsistent with inconsistent with the 
documentation. implementation. For 


example, documentation 
states audio files are 
signed but code indicates 
they are not. Numerous 
locations in documentation 
refer to an AES key of 256 
bits but the code shows it 
to be 128 bits. 
Inconsistency with 
documentation is a low 
severity, however since it 
relates to cryptography, it 
has a higher potential 
impact on the security of 





the system. 
22 |Unconventional The iButton uses an Type: Potential vulnerability 
authentication scheme. | unconventional Severity: Medium 


authentication scheme for 
authenticating users. It is 
unclear if this scheme is 


Might be exploited by a poll 
worker or elections official 





cryptographically sound. insider. 
23 |iButton functionality may | Bypassing the ¡Button Type: Vulnerability 
be bypassed. functionality requires write |Severity: Medium 


access to the configuration A , 
files of the ICC. This is a... Might be exploited by a poll 
debugging development worker, elections official insider, 


tool, but is active in the OF vendor Insider, 
production code. This 
would allow an attacker to 
read or alter anything 
protected by the principle 
encryption and integrity 





keys. 
24 Privilege escalation from One instance of possible Type: Vulnerability 
Administrator to privilege escalation was Severity: Medium 
Technician roles. identified. 


Might be exploited by a poll 
worker or elections official 
insider. 
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ID 


Description 


Assessment 


Categorization 





25 


Hard-coded encryption 
keys. 


Hard coded encryption 
keys expose the system to 
insider threat agents with 
expert knowledge or 
attackers who decompile 
and retrieve the keys from 
the executable. 


Type: Vulnerability 
Severity: Medium 


Might be exploited by a poll 
worker, elections official insider, 
or vendor insider. 





26 


No detection of overflows 
in arithmetic performed 
on vote counters. 


A 32-bit signed integer 
requires over 2 billion 
votes to overflow a 
counter. While statistically 
unlikely®, if an overflow 
were to occur, election 
results could be affected in 
unpredictable ways. 


Type: Weakness, VVSG 
nonconformity 
Severity: Medium 





27 


Sensitive keys are stored 
on disk unencrypted. 


These keys are used to 
protect keys used to 
encrypt and integrity 
protect the election 
definition and results. The 
keys are stored on the disk 
without their own 
protection. Gaining access 
to these files will grant 
logical access to the 
election definitions and 
results. Access controls on 
the underlying file system 
mitigate this threat. 


Type: Vulnerability 
Severity: Medium 





28 





Hard-coded key used to 
encrypt sensitive election 
information in the 
adjudication system. 








Hard-coded encryption 
keys expose the system to 
insider threat agents with 
expert knowledge or 
attackers who decompile 
and retrieve the keys from 
the executable. 





Type: Vulnerability 
Severity: Medium 











ê Page 85 of [VVSG2] explicitly states that assuming the counter size is large enough that the 
overflow value will never be reached is not adequate. 
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ID |Description 


Assessment 


Categorization 





29 |Poor quality keys 











Keys generated by the 
voting system have a 
relatively low amount of 
entropy making them 
easier to crack. It would 
take an insider with expert 
knowledge or someone 
who can decompile the 
executable binaries to 
exploit this vulnerability. 
The exploit could then be 
easily transferred to threat 
agents with no expertise. 
Considering the fact that 
almost all cryptographic 
functions of the system 
hinges on the strength of 
the keys, this is considered 
a high severity 
vulnerability. 





Type: Vulnerability 
Severity: High 


Might be exploited by any 
individual, voter or non-voter, 
who gains access to a compact 
flash memory card containing 
election data. 
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Glossary 

AES Advanced Encryption Standard 

API Application Programming Interface 

ATI Audio Tactile Interface 

AVS Accessible Voting Station 

CAVP Cryptographic Algorithm Validation Program 
CBC Cipher Block Chaining 

CMVP Cryptographic Module Validation Program 
COTS Commercial Off the Shelf 

CSP Critical Security Parameter 

CVE Common Vulnerability and Exposures 
CWE Common Weakness Enumeration 

DCF Device Configuration File 

DCM Data Center Manager 

ECDSA Elliptic Curve Digital Signature Algorithm 
EED Election Event Designer 

EMS Electronic Management System 

FIPS Federal Information Processing Standard 
HMAC Hash Message Authentication Code 
HTTP Hyper Text Transfer Protocol 

HTTPS Hyper Text Transfer Protocol Secure 

ICC ImageCast Central 

ICE ImageCast Evolution 

ICP ImageCast Precinct 

IP Internet Protocol 

IV Initialization Vector 

LAN Local Area Network 

LDF Log Data File 

MCF Machine Context File 

NAS Network Attached Storage 

OS Operating System 

PC Personal Computer 

RRH Result Receiver Host 

RSA Rivest, Shamir, and Adelman 

RTM Result Transfer Manager 

RTR Results Tally and Reporting 
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SHA Secure Hash Algorithm 

TCP Transmission Control Protocol 

USB Universal Serial Bus 

VIF Voter Information File 

VVSG Voluntary Voter System Guidelines 
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[FIPS198-1] National Institute of Standards and Technology, FIPS 198-1 The Keyed-Hash 
Message Authentication Code (HMAC), July 2008, 
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http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf. 
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